-
Notifications
You must be signed in to change notification settings - Fork 82
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
spec: Add cached update metadata #248
Conversation
Skipping CI for Draft Pull Request. |
In ostreedev/ostree-rs-ext#537 we added a facility to cache metadata (manifest+config) for container image updates with an eye for use in rpm-ostree. The `bootc update --check` code here in bootc was also updated to use it; but we didn't really expose it back in the status. This closes the gap, just bridging the cached update metadata into status. We want to do this as opposed to having `bootc update --check` grow its own API for example. Closes: containers#247 Signed-off-by: Colin Walters <[email protected]>
2ad49ae
to
b4a0145
Compare
This one needs some integration testing, which actually really wants us to improve our testing story in general. |
Although looking at this more, while this was easy to write and works, I think it's ergonomically odd because it's associated with a boot entry (as is how it's implemented today on the ostree side). But logically I think what we have in
|
Thinking about this a bit more, I think this is OK as is because it does make some sense to have a flow where:
Yet, there's no reason to logically toss away the cached update for the currently booted image. |
To test this out:
|
LGTM. By means of starting this on Friday and finishing it this morning I got the bonus of having the upstream eln image update itself to test against that:
(weekend goes by...)
|
In ostreedev/ostree-rs-ext#537 we added a facility to cache metadata (manifest+config) for container image updates with an eye for use in rpm-ostree.
The
bootc update --check
code here in bootc was also updated to use it; but we didn't really expose it back in the status.This closes the gap, just bridging the cached update metadata into status. We want to do this as opposed to having
bootc update --check
grow its own API for example.